The minimum level of bandwidth that a user needs to transmit data over an ATM network is typically negotiated with an ATM network administrator before the user transmits the data over the network. As a result of such negotiations, the level of bandwidth (access) that is awarded to the user is typically defined by a number of different traffic parameters, such as peak and average transmission rates. The network thereafter provides at least the level of access defined by the agreed-to parameters. In doing so the network "polices" the level of bandwidth that the user accesses during the transmission of data to ensure that the user's transmission of data conforms with the agreed-to parameters.
What this means is that the network admits only that level of traffic which conforms with the traffic parameters expected by the network. If the user transmits data at a level which does not conform with the expected parameters agreed to by the user, then the network may not admit the data into the network.
The prior art typically implements such policing using a so-called "leaky bucket" algorithm. That is, the network monitors the interval between successive ATM cells that it is receiving from the user and determines if the interval conforms with the expected associated traffic parameters. If an interval is found to be nonconforming, then the network may discard the incoming cell(s).
One problem in the way that the leaky bucket algorithm is used to police access to an ATM network is that the traffic parameters supplied to the algorithm are fixed for a particular user, which causes the algorithm to restrict the user to a particular level of bandwidth. Disadvantageously, then, the user cannot take advantage of bandwidth that becomes available along a route of a connection established for the user. It is likely then, that as a result of such restriction, the available bandwidth will remain idle until it is used by another user who accesses the ATM network.